<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- saved from url=(0039)https://martinfowler.com/microservices/ -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta content="uft-8" name="charset">

<title>Microservices Guide</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta content="summary" name="twitter:card">

<meta content="16665197" name="twitter:site:id">

<meta content="@martinfowler" name="twitter:site">

<meta content="Microservices Guide" property="og:title">

<meta content="https://martinfowler.com/microservices/" property="og:url">

<meta content="The microservice architectural style develops an application as a suite of independently deployable services." property="og:description">

<meta content="https://martinfowler.com/logo-sq.png" property="og:image">

<meta content="martinfowler.com" property="og:site_name">

<meta content="article" property="og:type">

<meta content="@martinfowler" name="twitter:creator">

<meta content="width=device-width, initial-scale=1" name="viewport">

<link href="../microservices.css" rel="stylesheet" type="text/css">
<meta http-equiv="origin-trial" content="AymqwRC7u88Y4JPvfIF2F37QKylC04248hLCdJAsh8xgOfe/dVJPV3XS3wLFca1ZMVOtnBfVjaCMTVudWM//5g4AAAB7eyJvcmlnaW4iOiJodHRwczovL3d3dy5nb29nbGV0YWdtYW5hZ2VyLmNvbTo0NDMiLCJmZWF0dXJlIjoiUHJpdmFjeVNhbmRib3hBZHNBUElzIiwiZXhwaXJ5IjoxNjk1MTY3OTk5LCJpc1RoaXJkUGFydHkiOnRydWV9"></head>

<body><header id="banner" style="background-image: url(&quot;/img/zakim.png&quot;); background-repeat: no-repeat">

<div class="name-logo"><a href="https://martinfowler.com/"><img src="../mf-name-white.png"></a></div>
  <div class="search">
    <!-- SiteSearch Google -->
    <form method="GET" action="https://www.google.com/search">
      <input type="hidden" name="ie" value="UTF-8">
      <input type="hidden" name="oe" value="UTF-8">
      <input class="field" type="text" name="q" size="15" maxlength="255" value="">
      <button class="button" type="submit" name="btnG" value=" " title="Search">
      <input type="hidden" name="domains" value="martinfowler.com">
      <input type="hidden" name="sitesearch" value=""> 
      <input type="hidden" name="sitesearch" value="martinfowler.com">
    
  </button></form></div>

<div class="menu-button navmenu-button"><a class="icon icon-bars" href="https://martinfowler.com/microservices/#navmenu-bottom"></a></div>

<nav class="top-menu">
<ul>
<li><a class="" href="https://refactoring.com/">Refactoring</a></li>

<li><a class="" href="https://martinfowler.com/agile.html">Agile</a></li>

<li><a class="" href="https://martinfowler.com/architecture">Architecture</a></li>

<li><a class="" href="https://martinfowler.com/aboutMe.html">About</a></li>

<li><a class="tw" href="https://www.thoughtworks.com/">Thoughtworks</a></li>

<li><a class="icon icon-rss" href="https://martinfowler.com/feed.atom" title="feed"></a></li>

<li><a class="icon icon-twitter" href="https://www.twitter.com/martinfowler" title="Twitter stream"></a></li>

<li class="icon"><a href="https://toot.thoughtworks.com/@mfowler" title="Mastodon stream"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512"><!--! Font Awesome Pro 6.2.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license (Commercial License) Copyright 2022 Fonticons, Inc. --><path d="M433 179.11c0-97.2-63.71-125.7-63.71-125.7-62.52-28.7-228.56-28.4-290.48 0 0 0-63.72 28.5-63.72 125.7 0 115.7-6.6 259.4 105.63 289.1 40.51 10.7 75.32 13 103.33 11.4 50.81-2.8 79.32-18.1 79.32-18.1l-1.7-36.9s-36.31 11.4-77.12 10.1c-40.41-1.4-83-4.4-89.63-54a102.54 102.54 0 0 1-.9-13.9c85.63 20.9 158.65 9.1 178.75 6.7 56.12-6.7 105-41.3 111.23-72.9 9.8-49.8 9-121.5 9-121.5zm-75.12 125.2h-46.63v-114.2c0-49.7-64-51.6-64 6.9v62.5h-46.33V197c0-58.5-64-56.6-64-6.9v114.2H90.19c0-122.1-5.2-147.9 18.41-175 25.9-28.9 79.82-30.8 103.83 6.1l11.6 19.5 11.6-19.5c24.11-37.1 78.12-34.8 103.83-6.1 23.71 27.3 18.4 53 18.4 175z"></path></svg></a></li>
</ul>
</nav>
</header>
<nav id="top-navmenu">
<nav class="navmenu">
<div class="nav-head">  <div class="search">
    <!-- SiteSearch Google -->
    <form method="GET" action="https://www.google.com/search">
      <input type="hidden" name="ie" value="UTF-8">
      <input type="hidden" name="oe" value="UTF-8">
      <input class="field" type="text" name="q" size="15" maxlength="255" value="">
      <button class="button" type="submit" name="btnG" value=" " title="Search">
      <input type="hidden" name="domains" value="martinfowler.com">
      <input type="hidden" name="sitesearch" value=""> 
      <input type="hidden" name="sitesearch" value="martinfowler.com">
    
  </button></form></div>

<div class="closediv">
<span class="close" title="close"></span>
</div>
</div>

<div class="nav-body">
<div class="topics">
<h2>Topics</h2>

<p><a href="https://martinfowler.com/architecture">Architecture</a></p>

<p><a href="https://refactoring.com/">Refactoring</a></p>

<p><a href="https://martinfowler.com/agile.html">Agile</a></p>

<p><a href="https://martinfowler.com/delivery.html">Delivery</a></p>

<p><a href="https://martinfowler.com/microservices">Microservices</a></p>

<p><a href="https://martinfowler.com/data">Data</a></p>

<p><a href="https://martinfowler.com/testing">Testing</a></p>

<p><a href="https://martinfowler.com/dsl.html">DSL</a></p>
</div>

<div class="about">
<h2>about me</h2>

<p><a href="https://martinfowler.com/aboutMe.html">About</a></p>

<p><a href="https://martinfowler.com/books">Books</a></p>

<p><a href="https://martinfowler.com/faq.html">FAQ</a></p>
</div>

<div class="content">
<h2>content</h2>

<p><a href="https://martinfowler.com/videos.html">Videos</a></p>

<p><a href="https://martinfowler.com/tags">Content Index</a></p>

<p><a href="https://martinfowler.com/articles/eurogames">Board Games</a></p>

<p><a href="https://martinfowler.com/photos">Photography</a></p>
</div>

<div class="tw">
<h2>Thoughtworks</h2>

<p><a href="https://thoughtworks.com/insights">Insights</a></p>

<p><a href="https://thoughtworks.com/careers">Careers</a></p>

<p><a href="https://thoughtworks.com/products">Products</a></p>
</div>

<div class="feeds">
<h2>follow</h2>

<p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

<p><a href="https://martinfowler.com/feed.atom">RSS</a></p>

<p><a href="https://toot.thoughtworks.com/@mfowler">Mastodon</a></p>
</div>
</div>
</nav>
</nav>

<main>
<h1>Microservices Guide</h1>

<section class="lede">
<section class="main">
<p>In short, the microservice architectural style is an
      approach to developing a single application as a <b>suite of small
      services</b>, each <b>running in its own process</b> and communicating with
      lightweight mechanisms, often an HTTP resource API. These
      services are <b>built around business capabilities</b> and
      <b>independently deployable</b> by fully automated deployment
      machinery. There is a <b>bare minimum of centralized management</b> of
      these services, which may be written in different programming
      languages and use different data storage
      technologies.</p>

<p>简而言之，微服务架构风格是一种将单一应用程序开发为<b>一套小型服务</b>的方法，
    每个服务都<b>在其自己的进程中运行</b>，
    并通过轻量级机制（通常是HTTP资源API）进行通信。
    这些服务是<b>围绕业务功能构建的</b>，并且可以通过完全自动化的部署机制<b>独立部署</b>。
    这些服务的集中管理<b>最少</b>，
    它们可能用不同的编程语言编写，
    并使用不同的数据存储技术。
</p>

<p>-- <a href="https://martinfowler.com/articles/microservices.html">James Lewis and Martin Fowler (2014)</a></p>

<p>-- <a href="../articles/microservices.html">詹姆斯·刘易斯和马丁·福勒（2014年）</a></p>
</section>

<section class="side">
<p class="explain">A guide to material on martinfowler.com about
      microservices.</p>

<div class="author">
<div class="photo"><a href="https://martinfowler.com/"><img alt="Photo of Martin Fowler" src="../mf.jpg" width="80"></a></div>

<address class="name"><a href="https://martinfowler.com/" rel="author">Martin Fowler</a></address>
</div>

<p class="date">
<time datetime="2019-08-21">21 Aug 2019</time>
</p>
</section>
</section>

<section class="row intro">
<section>
<p>Late in 2013, hearing all the discussion in my circles
      about microservices, I became concerned that there was no
      clear definition of microservices (a fate that <a href="https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html">caused many problems for
      SOA</a>). So I got together with my colleague <a href="https://twitter.com/boicy">James Lewis</a>, who was one of
      the more experienced practitioners of this style. Together we
      wrote</p>

<p>在2013年末，听到我的圈子里关于微服务的所有讨论，
    我开始担心微服务没有明确的定义（这种命运<a href="../bliki/ServiceOrientedAmbiguity.html">给SOA带来了许多问题</a>）。
    因此，我与我的同事<a href="https://twitter.com/boicy">詹姆斯·刘易斯（James Lewis）</a>聚在一起，他是这种风格的更有经验的实践者之一。
    我们一起撰写了
</p>

<section class="picture ms-article">
<p class="img-link"><a href="../articles/microservices.html"><img src="../ms-article.png"></a>
</p><p class="caption"></p>
<p></p>
</section>

<p>We wrote the article to provide <a href="https://martinfowler.com/articles/microservices.html">a firm definition for the
      microservices style</a>, which we did by listing the common
      characteristics of microservice architectures that we saw in the
      field.</p>
  
<p>我们撰写这篇文章是为了为<a href="../articles/microservices.html">微服务风格提供一个明确的定义</a>，
    我们通过列出在现场观察到的微服务架构的常见特征来实现这一点。
</p>

<ul class="common-chars">
<li>Componentization via Services</li>
<li>通过服务进行组件化</li>

<li>Organized around Business Capabilities</li>
<li>围绕业务能力组织</li>

<li>Products not Projects</li>
<li>产品而非项目</li>

<li>Smart endpoints and dumb pipes</li>
<li>智能端点和哑管道</li>

<li>Decentralized Governance</li>
<li>去中心化治理</li>

<li>Decentralized Data Management</li>
<li>去中心化数据管理</li>

<li>Infrastructure Automation</li>
<li>基础设施自动化</li>

<li>Design for failure</li>
<li>为失败设计</li>

<li>Evolutionary Design</li>
<li>演进式设计</li>
</ul>

<p>We also looked at common questions such as "how big is a
      microservice" and "what's the difference between microservices
      and Service-Oriented Architecture". The article catalyzed interest in
      microservices.</p>
      
<p>我们还探讨了常见问题，例如“微服务有多大”
    以及“微服务与面向服务的架构（Service-Oriented Architecture）之间的区别”。
    这篇文章激发了人们对微服务的兴趣。
</p>
</section>

<section>
<p class="quote">"Do we use it, do we not use it? </p>

<p class="quote">“我们是否使用它，我们是否不使用它？</p>

<p class="quote">… and what on earth is
      it in the first place?" </p>

<p class="quote">……首先，它到底是什么？”</p>

<section class="picture ms-talk">
<p class="img-link"><a href="https://martinfowler.com/videos.html#microservices"><img src="../ms-talk.png"></a>
</p><p class="caption"></p>
<p></p>
</section>

<p>In my <a href="https://martinfowler.com/videos.html#microservices">short introductory talk</a> (~25 minutes) I
      pick out the most important defining characteristics, compare
      microservices to monoliths, and outline the vital things to do
      before putting a first microservice system into
      production.</p>

<p>在我的<a href="https://martinfowler.com/videos.html#microservices">简短介绍演讲</a>（大约25分钟）中，
    我挑选出了最重要的定义特征，将微服务与单体架构进行了比较，
    并概述了在将首个微服务系统投入生产之前需要做的关键事项。
</p>
</section>
</section>

<hr class="sep">

<section class="synopsis when" id="WhenShouldWeUseMicroservices">
<h2>When should we use Microservices?</h2>

<p>Any architectural style has trade-offs: strengths and weaknesses that we
    must evaluate according to the context that it's used. This is certainly the
    case with microservices. While it's a useful architecture - many,
    indeed most, situations would do better with a monolith.</p>

<p>任何架构风格都有权衡：根据使用它的上下文，我们必须评估其优势和弱点。
    微服务架构当然也是如此。
    尽管它是一个有用的架构 —— 许多，实际上是最多的情况，使用单体架构会更好。
</p>

</section>

<section class="row trade-offs">
<section class="pros" id="MicroservicesProvideBenefitsx2026">
<h3>Microservices provide benefits…</h3>

<ul>
<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#boundaries">Strong Module Boundaries</a>: Microservices reinforce modular structure, which is
      particularly important for larger teams.</li>

<li><a href="../articles/microservice-trade-offs.html#boundaries">明确的模块边界</a>: 
    微服务强化了模块化结构，这对于大型团队尤为重要。</li>


<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#deployment">Independent Deployment</a>: Simple services are easier to deploy, and since they are
      autonomous, are less likely to cause system failures when they
      go wrong.</li>

<li><a href="../articles/microservice-trade-offs.html#deployment">独立开发</a>: 
    简单服务更容易部署，
    而且由于它们是自治的，因此在出错时不太可能导致系统故障。
</li>

<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#diversity">Technology Diversity</a>: With microservices you can mix multiple languages,
      development frameworks and data-storage technologies.</li>

<li><a href="../articles/microservice-trade-offs.html#diversity">技术多样性</a>：
    使用微服务，您可以将多种语言、开发框架和数据存储技术混合使用。</li>
</ul>
</section>

<section class="cons" id="x2026butComeWithCosts">
<h3>…but come with costs</h3>

<ul>
<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#distribution">Distribution</a>: Distributed systems are harder to program, since remote
      calls are slow and are always at risk of failure.</li>

<li><a href="../articles/microservice-trade-offs.html#distribution">分布式系统</a>：
    分布式系统更难编程，因为远程调用既缓慢又总是存在失败的风险。
</li>


<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#consistency">Eventual Consistency</a>: Maintaining strong consistency is extremely difficult for
      a distributed system, which means everyone has to manage
      eventual consistency.</li>

<li><a href="../articles/microservice-trade-offs.html#consistency">最终一致性</a>: 
    对于分布式系统来说，维持强一致性非常困难，
    这意味着每个人都必须处理最终一致性的问题。</li>

<li><a href="https://martinfowler.com/articles/microservice-trade-offs.html#ops">Operational Complexity</a>: You need a mature operations team to manage lots of
      services, which are being redeployed regularly.</li>

<li><a href="../articles/microservice-trade-offs.html#ops">运营复杂性</a>: 
    您需要一个成熟的运营团队来管理许多服务，这些服务需要经常重新部署。
</li>

</ul>
</section>
</section>

<section class="row trade-off-cite">
<section>
<p>(from <a href="https://martinfowler.com/articles/microservice-trade-offs.html">Microservice Trade-Offs</a>)</p>

<p>(从 <a href="../articles/microservice-trade-offs.html">微服务的权衡</a>)</p>

</section>
</section>

<section class="card-box">
<div class="article-card">
<h3><a href="../bliki/MicroservicePremium.html">Microservice Premium 微服务溢价</a></h3>

<div class="card-body">
<p class="card-image"><img src="../productivity.png"></p>

<p>The <a href="https://martinfowler.com/articles/microservices.html">microservices
  architectural style</a> has been the hot topic over the last year.
  At the recent <a href="http://softwarearchitecturecon.com/sa2015">O'Reilly software
  architecture conference</a>, it seemed like every session talked
  about microservices. Enough to get everyone's over-hyped-bullshit
  detector up and flashing. One of the consequences of this is that
  we've seen teams be too eager to embrace microservices,  not
  realizing that microservices introduce complexity on their own
  account. This adds a premium to a project's cost and risk - one that
  often gets projects into serious trouble. </p>

<p><a href="../articles/microservices.html">微服务架构风格</a>在过去一年里成为了热门话题。
    在最近的<a href="http://softwarearchitecturecon.com/sa2015">O'Reilly软件架构会议</a>上，似乎每个会议都在讨论微服务。
    足以让每个人的过度炒作废话检测器启动并闪烁。这
    种趋势的一个后果是，我们看到有些团队过于急切地接受微服务，
    没有意识到微服务本身就会引入复杂性。
    这增加了项目的成本和风险，往往使项目陷入严重的麻烦。
</p>

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">13 May 2015</p>

<p class="more"><a href="../bliki/MicroservicePremium.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> <span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../bliki/MonolithFirst.html">Monolith First 从单体应用开始</a></h3>

<div class="card-body">
<p class="card-image"><img src="../path.png"></p>

<p>As I hear stories about teams using a <a href="https://martinfowler.com/articles/microservices.html">microservices architecture</a>, I've
    noticed a common pattern.</p>
    
<p>当我听到有关团队使用<a href="../articles/microservices.html">微服务架构</a>的故事时，我注意到了一个常见的模式。
</p>

<ol>
<li>Almost all the successful microservice stories have started with a
      monolith that got too big and was broken up</li>

<li>几乎所有成功的微服务案例都是从一个小到变得过大而被分解的单体架构开始的。</li>

<li>Almost all the cases where I've heard of a system that was built as a
      microservice system from scratch, it has ended up in serious trouble.</li>
  
<li>几乎在我听说过的所有从头开始构建为微服务系统的案例中，这些系统最终都陷入了严重的麻烦。</li>
</ol>

<p>This pattern has led many of my colleagues to argue that <b>you
    shouldn't start a new project with microservices, even if you're
    sure your application will be big enough to make it worthwhile.
    </b>.</p>

<p>这种模式导致我的许多同事认为，
    即使您确信您的应用程序会足够大以至于采用微服务是值得的，
    <b>您也不应该从一开始就为一个新项目使用微服务。</b></p>

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">3 Jun 2015</p>

<p class="more"><a href="../bliki/MonolithFirst.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> <span class="tag-link"><a href="../tags/evolutionary%20design.html">evolutionary design</a></span> <span class="tag-link">
<a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../articles/dont-start-monolith.html">Don’t start with a monolith 不要从单体应用开始</a></h3>

<div class="card-body">
<p class="card-image"><img src="../monolith-theory-practice.png"></p>

<p> In the last few months, I’ve heard repeatedly that the only way to
get to a successful microservices architecture is by starting with a
monolith first. To
paraphrase Simon Brown: If you can’t build a well-structured
monolith, what makes you think you can build a well-structured set of
microservices? The most recent – and, as usual, very convincing –
rendering of this argument comes from Martin Fowler on this very site. As I had
a chance to comment on an earlier draft, I had some time to think
about this. And I did, especially because I usually find myself in
agreement with him, and some others whose views I typically share
seemed to agree with him, too.
</p>

<p> 在过去的几个月里，我反复听到的一个观点是，
    要想成功实现微服务架构，唯一的方法是先从单体架构开始。
    用Simon Brown的话来说：如果你不能构建一个结构良好的单体，你怎么会认为你能构建一组结构良好的微服务呢？
    这个观点在Martin Fowler的这篇文章中得到了最新且非常有说服力的阐述。
    由于我有机会评论一个早期草案，我有一些时间来思考这个问题。
    我确实思考了，尤其是因为我通常发现自己同意他的观点，
    而且一些我通常认同的其他人的观点似乎也同意他的看法。
</p>

<p>I’m firmly convinced that starting with a monolith is usually exactly the
wrong thing to do. 
</p>

<p>我坚信，从单体架构开始通常正是错误的做法。
</p>

<div class="meta">
<p class="credits">by Stefan Tilkov</p>

<p class="date">9 Jun 2015</p>

<p class="more"><a href="../articles/dont-start-monolith.html">Read more…</a></p>

<p class="type article">article</p>

<p class="tags"> <span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../bliki/MicroservicePrerequisites.html">Microservice Prerequisites 微服务先决条件</a></h3>

<div class="card-body">
<p class="card-image"><img src="../sketch.png"></p>

<p>As I talk to people about using a <a href="https://martinfowler.com/articles/microservices.html">microservices architectural
  style</a> I hear a lot of optimism. Developers enjoy working with
  smaller units and have expectations of better modularity than with
  monoliths. But as with any architectural decision there are
  trade-offs. In particular with microservices there are serious
  consequences for operations, who now have to handle an ecosystem of
  small services rather than a single, well-defined monolith.
  Consequently if you don't have certain baseline competencies, you
  shouldn't consider using the microservice style.</p>


<p>当我和人们讨论使用<a href="../articles/microservices.html">微服务架构风格</a>时，我听到了很多乐观的言论。
    开发人员喜欢使用更小的单元工作，并且期望比单体架构有更好的模块化。
    但与任何架构决策一样，都有权衡。
    特别是对于微服务，对运维人员来说有严重的后果，
    因为他们现在必须处理一个小型服务的生态系统，而不是一个单一、明确定义的单体。
    因此，如果您没有某些基本能力，您就不应该考虑使用微服务风格。
</p>

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">28 Aug 2014</p>

<p class="more"><a href="../bliki/MicroservicePrerequisites.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> <span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../articles/distributed-objects-microservices.html">Microservices and the First Law of Distributed
  Objects 微服务与分布式对象的第一法则</a></h3>

<div class="card-body">
<p class="card-image"><img src="../local-remote.png"></p>

<p class="abstract">
    In P of EAA I said "don't distribute your objects". Does this
    advice contradict my interest in Microservices? 
  </p>

<p class="abstract">
    在《企业应用架构模式》（P of EAA）一书中，我说过“不要分布式你的对象”。
    这些建议是否与我对微服务的兴趣相矛盾？
</p>

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">13 Aug 2014</p>

<p class="more"><a href="../articles/distributed-objects-microservices.html">Read more…</a></p>

<p class="type article">article</p>

<p class="tags"> <span class="tag-link"><a href="../tags/API%20design.html">API design</a></span> 
<span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="https://gotopia.tech/bookclub/episodes/moving-to-microservices-with-sam-newman-and-martin-fowler">
Interview with Sam Newman about Microservices 采访Sam Newman关于微服务
</a></h3>

<div class="card-body">
<p class="card-image"><img src="../goto-book-newman.png"></p>

<p class="abstract">
    goto conferences asked me to do an interview with Sam Newman on his book:
     "Monoliths to Microservices". This turned into a general conversation about
     microservices and when to use them. Sam considers the three main reasons
     for them to be independent deployability, isolation of data, and reflecting
     the organizational structure. I'm more skeptical of the first, but consider
     data and people to be complicated parts of software development.
  </p>


<p class="abstract">
    goto conferences邀请我采访Sam Newman关于他的书《单体到微服务》。
    这变成了关于微服务以及何时使用它们的普遍对话。
    Sam认为使用微服务的三个主要原因是独立可部署性、数据的隔离性和反映组织结构。
    我对于第一个原因更加持怀疑态度，但认为数据和人是软件开发中复杂的部分。
  </p>

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">4 Sep 2020</p>

<p class="more"><a href="https://gotopia.tech/bookclub/episodes/moving-to-microservices-with-sam-newman-and-martin-fowler">More…</a></p>

<p class="type video">video</p>

<p class="tags"> <span class="tag-link"><a href="../tags/interviews.html">interviews</a></span> <span class="tag-link">
<a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>
</section>

<hr class="sep">

<section class="row building">
<section id="BuildingMicroservices">
<h2>Building Microservices</h2>

<p>Microservice architectures are fairly new, but I've been fortunate that
    we've worked with them at Thoughtworks since their <a href="https://www.thoughtworks.com/radar/techniques/microservices">earliest appearances</a>. For a cohesive description of how
    best to work with them, the best introduction is Sam Newman's book <a href="https://www.amazon.com/gp/product/1491950358/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=1491950358&amp;linkCode=as2&amp;tag=martinfowlerc-20">Building Microservices</a> which he wrote based on
    our experiences and other published accounts.</p>

<p>微服务架构相对较新，但我很幸运，自从它们<a href="https://www.thoughtworks.com/radar/techniques/microservices">最早出现</a>以来，
    我们就在Thoughtworks与它们合作过。
    为了了解如何最佳地使用微服务，最好的入门书籍是Sam Newman基于我们的经验和其他已发布案例编写的《构建微服务》
    （<a href="https://www.amazon.com/gp/product/1491950358/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=1491950358&amp;linkCode=as2&amp;tag=martinfowlerc-20">Building Microservices</a>）。
</p>

</section>

<section>
<section class="picture book">
<p class="img-link"><a href="https://www.amazon.com/gp/product/1491950358/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=1491950358&amp;linkCode=as2&amp;tag=martinfowlerc-20"><img src="../newman-book.jpg"></a>
</p><p class="caption"></p>
<p></p>
</section>
</section>
</section>

<section class="card-box">
<div class="article-card">
<h3><a href="../articles/microservice-testing">Testing Strategies in a Microservice Architecture 微服务架构的测试策略</a></h3>

<div class="card-body">
<p class="card-image"><img src="../meta-image.png"></p>

<p class="abstract">
        There has been a shift in service based architectures over the last few
        years towards smaller, more focussed "micro" services. There are many
        benefits with this approach such as the ability to independently
        deploy, scale and maintain each component and
        parallelize development across multiple teams. However,
        once these additional network partitions have been introduced, the
        testing strategies that applied for monolithic in process applications
        need to be reconsidered.
       
        Here, we plan to discuss a number of approaches for managing
        the additional testing complexity of multiple independently
        deployable components as well as how to have tests and the application
        remain correct despite having multiple teams each acting as guardians for
        different services.
       </p>


<p class="abstract">
    在过去几年中，基于服务的架构已经转向了更小、更专注的“微”服务。
    这种方法有许多好处，例如能够独立部署、扩展和维护每个组件，并可以并行化开发跨多个团队。
    然而，一旦引入了这些额外的网络分区，适用于单体内部应用程序的测试策略需要重新考虑。
    在这里，我们计划讨论一些方法，
    用于管理多个独立可部署组件的额外测试复杂性，
    以及如何使测试和应用程序保持正确性，
    尽管有多个团队各自作为不同服务的守护者。
</p>

<div class="meta">
<p class="credits"><credits>by Toby Clemson</credits></p>

<p class="date">18 Nov 2014</p>

<p class="more"><a href="../articles/microservice-testing">Read more…</a></p>

<p class="type infodeck">infodeck</p>

<p class="tags"> <span class="tag-link"><a href="../tags/popular.html">popular</a></span> <span class="tag-link">
<a href="../tags/testing.html">testing</a></span> 
<span class="tag-link"><a href="https://../tags/infodecks.html">infodecks</a></span> 
<span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../articles/break-monolith-into-microservices.html">How to break a Monolith into Microservices 如何把一个单体应用拆分为微服务</a></h3>

<div class="card-body">
<p class="card-image"><img src="../sketch(1).png"></p>

<p class="abstract">As monolithic systems become too large to deal with, many
  enterprises are drawn to breaking them down into the microservices
  architectural style. It is a worthwhile journey, but not an easy one. We've
  learned that to do this well, we need to start with a simple service, but then
  draw out services that are based on vertical capabilities that are important
  to the business and subject to frequent change. These services should be large
  at first and preferably not dependent upon the remaining monolith. We should
  ensure that each step of migration represents an atomic improvement to the
  overall architecture.</p>

<p class="abstract">当单体系统变得过大而难以处理时，许多企业转向将它们分解为微服务架构风格。
    这是一次值得的旅程，但并非易事。
    我们了解到，为了做到这一点，我们首先需要从一个简单的服务开始，然后根据业务中重要且经常变化的垂直能力提取服务。
    这些服务最初应该是大的，并且最好不依赖于剩余的单体。
    我们应该确保迁移的每一步代表对整体架构的原子性改进。
</p>

<div class="meta">
<p class="credits">by Zhamak Dehghani</p>

<p class="date">24 Apr 2018</p>

<p class="more"><a href="../articles/break-monolith-into-microservices.html">Read more…</a></p>

<p class="type article">article</p>

<p class="tags"> <span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> 
<span class="tag-link"><a href="../tags/legacy%20rehab.html">legacy rehab</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../articles/micro-frontends.html">Micro Frontends 微前端</a></h3>

<div class="card-body">
<p class="card-image"><img src="../card.png"></p>

<p class="abstract">
    Good frontend development is hard. Scaling frontend development so that many
    teams can work simultaneously on a large and complex product is even harder.
    In this article we'll describe a recent trend of breaking up frontend
    monoliths into many smaller, more manageable pieces, and how this
    architecture can increase the effectiveness and efficiency of teams working
    on frontend code. As well as talking about the various benefits and costs,
    we'll cover some of the implementation options that are available, and we'll
    dive deep into a full example application that demonstrates the technique.
  </p>

<p class="abstract">
    前端开发很困难。
    让许多团队能够同时在一个大而复杂的产品的不同部分工作，更是难上加难。
    在这篇文章中，我们将描述一个最近趋势，即将前端单体拆分为许多更小、更易于管理的部分，
    以及这种架构如何提高团队在前端代码工作的有效性和效率。
    除了讨论各种好处和成本之外，我们还将介绍一些可用的实施选项，
    并深入探讨一个完整的示例应用程序，该应用程序展示了这种技术。
  </p>
  

<div class="meta">
<p class="credits">by Cam Jackson</p>

<p class="date">19 Jun 2019</p>

<p class="more"><a href="../articles/micro-frontends.html">Read more…</a></p>

<p class="type article">article</p>

<p class="tags"> <span class="tag-link"><a href="../tags/application%20architecture.html">application architecture</a></span> 
<span class="tag-link"><a href="../tags/front-end.html">front-end</a></span> 
<span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../articles/extract-data-rich-service.html">How to extract a data-rich service from a monolith 从单体架构中提取一个数据丰富的服务
</a></h3>

<div class="card-body">
<p class="card-image"><img src="../card(1).png"></p>

<p class="abstract">When breaking monoliths into smaller services, the hardest part is
  actually breaking up the data that lives in the database of the monolith. To
  extract a data-rich service, it is useful to follow a series of steps which
  retain a single write-copy of the data at all times. The steps begin by making
  a logical separation in the existing monolith: splitting service behavior into
  a separate module, then separating data into a separate table. These elements
  can be separately moved into a new autonomous service.</p>


<p class="abstract">当将单体架构拆分为更小的服务时，实际上从单体数据库中拆分数据是最困难的部分。
    为了提取一个数据丰富的服务，遵循一系列步骤是有用的，
    这些步骤始终保留数据的单一写入副本。
    这些步骤从现有的单体中进行逻辑分离开始：
    将服务行为拆分为一个单独的模块，
    然后将数据拆分为一个单独的表。
    这些元素可以分别移动到一个新的自主服务中。
</p>
  
<div class="meta">
<p class="credits">by Praful Todkar</p>

<p class="date">30 Aug 2018</p>

<p class="more"><a href="../articles/extract-data-rich-service.html">Read more…</a></p>

<p class="type article">article</p>

<p class="tags"> 
<span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> 
<span class="tag-link"><a href="../tags/legacy%20rehab.html">legacy rehab</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../bliki/InfrastructureAsCode.html">Infrastructure As Code 基础设施即代码</a></h3>

<div class="card-body">
<p class="card-image"><img src="../card(2).png"></p>

<p>Infrastructure as code is the approach to defining computing and network
  infrastructure through source code that can then be treated just like any software
  system. Such code can be kept in source control to allow auditability and
  <a href="https://martinfowler.com/bliki/ReproducibleBuild.html">ReproducibleBuilds</a>, subject to testing practices, and the full discipline of
  <a href="https://martinfowler.com/bliki/ContinuousDelivery.html">ContinuousDelivery</a>. It's an approach that's been used over the last decade to
  deal with growing <a href="https://martinfowler.com/bliki/CloudComputing.html">CloudComputing</a> platforms and will become the dominant way
  to handle computing infrastructure in the next.</p>


<p>基础设施即代码（Infrastructure as Code，简称IaC）是一种通过源代码定义计算和网络基础设施的方法，
    这种方法可以将基础设施的配置视为与任何软件系统一样进行管理。
    这样的代码可以存储在源代码控制系统中，
    以便进行审计和<a href="../bliki/ReproducibleBuild.html">可重现构建（Reproducible Builds）</a>，
    接受测试实践的约束，
    并完全遵循<a href="../bliki/ContinuousDelivery.html">持续交付（Continuous Delivery）</a>的纪律。
    在过去的十年中，这种方法已被用来处理日益增长的<a href="../bliki/CloudComputing.html">云计算平台</a>，
    并将在未来成为处理计算基础设施的主导方式。
</p>
  

<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">1 Mar 2016</p>

<p class="more"><a href="../bliki/InfrastructureAsCode.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> 
<span class="tag-link"><a href="../tags/continuous%20delivery.html">continuous delivery</a></span> 
<span class="tag-link"><a href="../tags/microservices.html">microservices</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../bliki/DevOpsCulture.html">Dev Ops Culture</a></h3>

<div class="card-body">
<p class="card-image"><img src="https://martinfowler.com/microservices/"></p>

<p>Agile software development has broken down some of the silos
  between requirements analysis, testing and development. Deployment,
  operations and maintenance are other activities which have suffered a similar
  separation from the rest of the software development process. The
  DevOps movement is aimed at removing these silos and encouraging
  collaboration between development and operations.</p>

<p>敏捷软件开发已经打破了需求分析、测试和开发之间的一些壁垒。
    部署、运营和维护等活动也经历了与软件开发过程其他部分的类似分离。
    DevOps运动旨在消除这些壁垒，并鼓励开发和运营之间的合作。
</p>

<div class="meta">
<p class="credits">by Rouan Wilsenach</p>

<p class="date">9 Jul 2015</p>

<p class="more"><a href="../bliki/DevOpsCulture.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> 
<span class="tag-link"><a href="../tags/continuous%20delivery.html">continuous delivery</a></span> 
<span class="tag-link"><a href="../tags/agile%20adoption.html">agile adoption</a></span> 
<span class="tag-link"><a href="../tags/team%20organization.html">team organization</a></span> 
<span class="tag-link"><a href="../tags/collaboration.html">collaboration</a></span> </p>
</div>
</div>
</div>

<div class="article-card">
<h3><a href="../bliki/CircuitBreaker.html">Circuit Breaker 断路器</a></h3>

<div class="card-body">
<p class="card-image"><img src="../card(3).png"></p>

<p>It's common for software systems to make remote calls to software
  running in different processes, probably on different machines
  across a network. One of the big differences between in-memory calls
  and remote calls is that remote calls can fail, or hang without a
  response until some timeout limit is reached. What's worse if you
  have many callers on a unresponsive supplier, then you can run out
  of critical resources leading to cascading failures across multiple
  systems. In his excellent book <a href="https://www.amazon.com/gp/product/0978739213/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0978739213&amp;linkCode=as2&amp;tag=martinfowlerc-20">Release
  It</a>, Michael Nygard popularized the Circuit Breaker pattern to
  prevent this kind of catastrophic cascade.</p>


<p>在不同的进程中运行的软件系统之间进行远程调用是常见的，这些进程可能位于网络上的不同机器上。
    内存调用和远程调用之间的一个主要区别是，远程调用可能会失败，
    或者在没有响应的情况下挂起，直到达到某个超时限制。
    更糟糕的是，如果您有许多调用者在一个无响应的供应商上，
    那么您可能会耗尽关键资源，导致在多个系统之间发生级联故障。
    在Michael Nygard的优秀书籍《Release It》中，他普及了电路断路器模式，以防止这种灾难性的级联。
</p>


<p>The basic idea behind the circuit breaker is very simple. You
  wrap a protected function call in a circuit breaker object, which monitors for
  failures. Once the failures reach a certain threshold, the circuit
  breaker trips, and all further calls to the circuit breaker return
  with an error, without the protected call being made at all. Usually
  you'll also want some kind of monitor alert if the circuit breaker
  trips.</p>


<p>电路断路器背后的基本思想非常简单。
    您在一个电路断路器对象中包装一个受保护的函数调用，该对象监测失败情况。
    一旦失败次数达到某个阈值，电路断路器就会跳闸，
    所有进一步的电路断路器调用都会返回错误，而不会实际进行受保护的调用。
    通常，您还希望在高电路断路器跳闸时有一些监控警报。
</p>


<div class="meta">
<p class="credits">by Martin Fowler</p>

<p class="date">6 Mar 2014</p>

<p class="more"><a href="../bliki/CircuitBreaker.html">Read more…</a></p>

<p class="type bliki">bliki</p>

<p class="tags"> <span class="tag-link"><a href="https://martinfowler.com/tags/continuous%20delivery.html">continuous delivery</a></span> <span class="tag-link"><a href="https://martinfowler.com/tags/application%20architecture.html">application architecture</a></span> </p>
</div>
</div>
</div>
</section>
</main>

<nav id="bottom-navmenu" style="display: none;">
<nav class="navmenu">
<div class="nav-head">  <div class="search">
    <!-- SiteSearch Google -->
    <form method="GET" action="https://www.google.com/search">
      <input type="hidden" name="ie" value="UTF-8">
      <input type="hidden" name="oe" value="UTF-8">
      <input class="field" type="text" name="q" size="15" maxlength="255" value="">
      <button class="button" type="submit" name="btnG" value=" " title="Search">
      <input type="hidden" name="domains" value="martinfowler.com">
      <input type="hidden" name="sitesearch" value=""> 
      <input type="hidden" name="sitesearch" value="martinfowler.com">
    
  </button></form></div>

<div class="closediv">
<span class="close" title="close"></span>
</div>
</div>

<div class="nav-body">
<div class="topics">
<h2>Topics</h2>

<p><a href="https://martinfowler.com/architecture">Architecture</a></p>

<p><a href="https://refactoring.com/">Refactoring</a></p>

<p><a href="https://martinfowler.com/agile.html">Agile</a></p>

<p><a href="https://martinfowler.com/delivery.html">Delivery</a></p>

<p><a href="https://martinfowler.com/microservices">Microservices</a></p>

<p><a href="https://martinfowler.com/data">Data</a></p>

<p><a href="https://martinfowler.com/testing">Testing</a></p>

<p><a href="https://martinfowler.com/dsl.html">DSL</a></p>
</div>

<div class="about">
<h2>about me</h2>

<p><a href="https://martinfowler.com/aboutMe.html">About</a></p>

<p><a href="https://martinfowler.com/books">Books</a></p>

<p><a href="https://martinfowler.com/faq.html">FAQ</a></p>
</div>

<div class="content">
<h2>content</h2>

<p><a href="https://martinfowler.com/videos.html">Videos</a></p>

<p><a href="https://martinfowler.com/tags">Content Index</a></p>

<p><a href="https://martinfowler.com/articles/eurogames">Board Games</a></p>

<p><a href="https://martinfowler.com/photos">Photography</a></p>
</div>

<div class="tw">
<h2>Thoughtworks</h2>

<p><a href="https://thoughtworks.com/insights">Insights</a></p>

<p><a href="https://thoughtworks.com/careers">Careers</a></p>

<p><a href="https://thoughtworks.com/products">Products</a></p>
</div>

<div class="feeds">
<h2>follow</h2>

<p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

<p><a href="https://martinfowler.com/feed.atom">RSS</a></p>

<p><a href="https://toot.thoughtworks.com/@mfowler">Mastodon</a></p>
</div>
</div>
</nav>
</nav>
<footer id="page-footer">
<div class="tw-logo">
<a href="http://www.thoughtworks.com/">
<img src="../thoughtworks_white.png">
</a>
</div>
<div class="menu-button">
<div class="icon-bars navmenu-button"></div>
</div>
<div class="copyright">
<p>© Martin Fowler | <a href="http://www.thoughtworks.com/privacy-policy">Privacy Policy</a> | <a href="https://martinfowler.com/aboutMe.html#disclosures">Disclosures</a></p>
</div>
</footer>
<!-- Google Analytics -->
<!-- old Google Universal -->
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-17005812-1', 'auto');
ga('send', 'pageview');
</script>
<script async="" src="../analytics.js"></script>
<!-- New Google GA4 -->
<!-- global site tag (gtag.js) - Google Analytics -->
<script async="" src="../js"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-6D51F4BDVF');
</script>
<!-- End Google Analytics -->



<script src="../jquery-1.11.3.min.js" type="text/javascript"></script>

<script src="../mfcom.js" type="text/javascript"></script>

<script type="text/javascript">encloseWhenSmall('.article-card', 'h3');
</script>


</body></html>